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Status of this Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 
Copyright Notice 
Copyright (C) The Internet Society (2003). All Rights Reserved. 
Abstract 
This document specifies a Resource ReSerVation Protocol-Traffic 
Engineering (RSVP-TE) signaling extension for support of Asynchronous 
Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching 


(MPLS) Traffic Engineering. 
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1. Overview 


This document defines a Resource ReSerVation Protocol-Traffic 
Engineering (RSVP-TE) protocol addition to support ATM (Asynchronous 
Transfer Mode) Service Class-aware MPLS (MultiProtocol Label 
Switching) Traffic Engineering. 


This protocol addition is used with all MPLS Label Switched Routers 
(LSRs) and link types (including, but not restricted to, Packet over 
SONET, Ethernet, and ATM links) to signal traffic engineered paths 
that can support the ATM service classes as defined by the ATM Forum 
[TM]. This document does not specify HOW to actually implement the 
functionality in the MPLS LSRs to emulate the ATM Forum service 
classes (such as necessary queuing and scheduling mechanisms), only 
how to signal that the TE path must support the ATM Forum service 
classes. A useful application for such paths is the carriage of ATM 
cells encapsulated in IP or MPLS packets in order to use MPLS 
networks as functional replacements for ATM networks. 


2. Extended RSVP-TE Path Message Format 


One new RSVP-TE Object is defined in this document: the 
ATM_SERVICECLASS Object. Detailed description of this Object is 
provided below. This new Object is applicable to PATH messages. 
This specification only defines the use of the ATM_SERVICECLASS 
Object in PATH messages used to establish LSP (Label Switched Path) 
Tunnels in accordance with [RSVP-TE]. Such PATH messages contain a 
Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and a 

LABEL REQUEST object. 


Restrictions defined in [RSVP-TE] for support of establishment of LSP 
Tunnels via RSVP-TE are also applicable to the establishment of LSP 
Tunnels supporting ATM Service Class-aware traffic engineering. For 
instance, only unicast LSPs are supported and Multicast LSPs are for 
further study. 


This new ATM_SERVICECLASS object is optional with respect to RSVP-TE 
so that general RSVP-TE implementations not concerned with ATM 
Service Class-aware traffic engineering MPLS LSP setup do not have to 
support this object. 


Malis & Hsiao Informational [Page 2] 


RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003 


2.1 PATH Message Format 
The format of the extended PATH message is as follows: 


<PATH Message> ::= <Common Header> [ <INTEGRITY> ] 
<SESSION> <RSVP_HOP> 

<TIME_VALUES> 

[ <EXPLICIT_ROUTE> ] 

<LABEL REQUEST> 

[ <SESSION_ATTRIBUTE> ] 
<DIFFSERV> ] 
<ATM_SERVICECLASS> ] 
<POLICY_DATA> ... ] 
<sender descriptor> ] 


mman a 


<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ] 
[ <ADSPEC> ] 
[ <RECORD_ROUTE> ] 


3. ATM_SERVICECLASS Object 
The ATM_SERVICECLASS object format is as follows: 
Class Number = 227, C_Type = 1 


0 1 2 3 
Os 203? 4b EE YS BOO! TID? 3s AS 156s 8. Ge OL 2) 3h 4-5 6: Ye -B.92 0:1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++H 
| Reserved | sc | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++t++ 


Reserved : 29 bits 


This field is reserved. It must be set to zero on transmission 
and must be ignored on receipt. 


SC % 3 bits 
Indicates the ATM Service Class. Values currently allowed are: 
0: UBR (Unspecified Bit Rate) 

VBR-NRT (Variable Bit Rate, Non-Real Time) 

VBR-RT (Variable Bit Rate, Real Time) 

CBR (Constant Bit Rate) 

-7: reserved 


AUNE 
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4. Handling the ATM_SERVICECLASS Object 


To establish an LSP tunnel with RSVP-TE, the sender LSR creates a 
PATH message with a session type of LSP_Tunnel_IPv4 and with a 
LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also 
include the DIFFSERV object as per [DIFF-MPLS]. 


If the LSP is associated with an ATM Service Class, the sender LSR 
must include the ATM_SERVICECLASS object in the PATH message with the 
Service-Class (SC) field set to signify the desired ATM Service 
Class. 


If a path message contains multiple ATM_SERVICECLASS objects, only 
the first one is meaningful; subsequent ATM_SERVICECLASS object (s) 
must be ignored and must not be forwarded. 


Each LSR along the path that is ATM_SERVICECLASS-aware records the 
ATM_SERVICECLASS object, when present, in its path state block. 


The destination LSR responds to the PATH message by sending a RESV 
message without an ATM_SERVICECLASS object (whether the PATH message 
contained an ATM_SERVICECLASS object or not). 


5. Non-support of the ATM_SERVICECLASS Object 


An LSR that does not recognize the ATM_SERVICECLASS object Class 
Number must behave in accordance with the procedures specified in 
[RSVP] for an unknown Class Number with the binary format 11bbbbbb, 
where b=0 or 1 (i.e., RSVP will ignore the object but forward it 
unexamined and unmodified). 


An LSR that recognizes the ATM_SERVICECLASS object Class Number but 
does not recognize the ATM_SERVICECLASS object C-Type, must behave in 
accordance with the procedures specified in [RSVP] for an unknown 
C-type (i.e., it must send a PathErr with the error code ’Unknown 
object C-Type’ toward the sender). 


In both situations, this causes the path setup to fail. The sender 
should notify management that a LSP cannot be established and 
possibly might take action to retry reservation establishment without 
the ATM_SERVICECLASS object. 


6. Security Considerations 


The solution is not expected to add specific security requirements 


beyond those of Diff-Serv and existing TE. The security mechanisms 
currently used with Diff-Serv and existing TE can be used with this 
solution. 
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7. IANA Considerations 


The IANA has registered a new RSVP Class Number for ATM_SERVICECLASS 
(227). (See http://www.iana.org/assignments/rsvp-parameters). 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Acknowledgement 


Funding for the RFC Editor function is currently provided by the 
Internet Society. 


Malis & Hsiao Informational [Page 6] 


